Add support for creating self-decrypting binaries #2315
+112
−10
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
will-v-pi
force-pushed
the
self-decrypting-only
branch
from
e684dcc to
4c7b909
Compare
will-v-pi
force-pushed
the
self-decrypting-only
branch
from
4c7b909 to
fd83496
Compare
will-v-pi
added a commit
to raspberrypi/picotool
that referenced
this pull request
Apr 22, 2025
…e examples compilation passes
lurch
reviewed
Apr 24, 2025
lurch
reviewed
Apr 24, 2025
lurch
reviewed
Apr 24, 2025
will-v-pi
added a commit
to raspberrypi/picotool
that referenced
this pull request
Apr 28, 2025
…e examples compilation passes
lurch
reviewed
Apr 28, 2025
For now, this function embeds the decrypting bootloader, but probably better to integrate (or replace) existing pico_encrypt_binary function
Add newlines for readability, and explain why MbedTLS version is insecure
will-v-pi
force-pushed
the
self-decrypting-only
branch
from
c0f179f to
fdc61ca
Compare
lurch
reviewed
May 19, 2025
| # This sets the target properties PICOTOOL_AESFILE to AESFILE, PICOTOOL_IVFILE to IVFILE, and | ||
| # PICOTOOL_ENC_SIGFILE to SIGFILE if specified, else PICOTOOL_SIGFILE. | ||
| # | ||
| # Optionally, use EMBED to embed a decryption stage into the encrypted binary. |
There was a problem hiding this comment.
Another stupid question: when/why would you not want to embed a decryption stage into the encrypted binary?
lurch
reviewed
May 19, 2025
| # and takes up more code size. | ||
| # This sets the target property PICOTOOL_USE_MBEDTLS_DECRYPTION to TRUE. | ||
| # | ||
| # Optionally, use OTP_KEY_PAGE to specify the OTP page storing the AES key. |
There was a problem hiding this comment.
Does this have some default or implicit value, if not explicitly set?
There was a problem hiding this comment.
Is this same OTP page (or some fixed offset from it) also used for storing the IV salt, or might it make sense to have an OTP_SALT_PAGE parameter?
The embedded decryption stage only works if the binary is written to Flash and then loaded to SRAM by the bootrom
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds extra functionality to the
pico_encrypt_binaryfunction to allow creating self-decrypting binaries, including specifying the OTP page to use for the AES key.pico_encrypt_binary(hello_encrypted ${CMAKE_CURRENT_LIST_DIR}/privateaes.bin ${CMAKE_CURRENT_LIST_DIR}/ivsalt.bin EMBED OTP_KEY_PAGE 29)The main non-backwards-compatible change is the addition of a new IV salt bin file which is required and must be passed as the second argument. This will break any uses of
pico_encrypt_binary, and has been added for security purposes, as we now salt the public IV with a salt stored in OTP.The other non-backwards-compatible change it that if you previously called:
you now need to call
due to the new argument parsing. I think that this is fine, because the only time you'd pass a separated
SIGFILEtopico_encrypt_binaryis when you're using a different signing key for the binary vs the encrypted blob, which is not a common use case.This PR requires use of the picotool encrypted-shares branch (raspberrypi/picotool#207), so should be merged after that.